\subsection{Comparison with other multi-chain systems}\label{sec:comparison}
\subsubsection{ETH2.0}
\input{eth2_comp}

\subsubsection{Sidechains}
An alternative way to scale blockchain technologies are using side-chains \footnote{that allow tokens from one blockchain to be considered valid on an independent blockchain and be used there}. These solutions are also addressing interoperability, in that they enabling bridging side chains to the main chain. For example, for Eth1.0 many side-chains were introduced that contributed to scalability such as Plasma Cash and Loom \footnote{https://loomx.io}.
A prominent solution that is solely based on bridging independent chains to each other is Cosmos \footnote{https://cosmos.network} that is reviewed and compared to Polkadot next.

%\paragraph{ETH1.0 Sidechains, e.g., Plasma Cash}
%TODO

\subsubsection{Cosmos}

Cosmos is a system designed to solve the blockchain interoperability problem that is fundamental to improve the scalability for the decentralized web. In this sense, there are surface similarities between the two systems. Hence, Cosmos consists of components which play similar roles and resemble the sub-components of Polkadot. For example, the Cosmos Hub is used to transfer messages between Comos' zones similarly to how the Polkadot Relay Chain oversees the passing of messages among Polkadot parachains.

There are however significant differences between the two systems. Most importantly, while the Polkadot system as a whole is a sharded state machine (see Section \ref{sec:relaychain}), Cosmos does not attempt to unify the state among the zones and so the state of individual zones is not reflected in the Hub's state. As a result, a similar property as the shared security offered by Polkadot is absence in Cosmos system. Consequently, the Cosmos cross-chain messages, are no longer trust-less and the onus is on the user to trust the (validators of) sending and the receiving zones (and optionally the Hub if it is involved in the cross transaction) to engage in a particular transaction. As such the security of the user's transaction is bounded to the security least secure chain participating in that transaction. 

Similarly, the security promise of Polkadot guarantees that validated parachain data are available at a later time for retrieval and audit (see Section \ref{sec:validity-and-availability}). In contrast,  Cosmos's trust model does not guarantee any security assumption regarding the participating zones (and in particular regarding the availability of the their data). Therefore, the users are ought to trust the zone operators to keep the history of the chain state.

It is noteworthy that using the SPREE modules, Polkadot offers even stronger security than the shared security.
%(See Section \ref{sec:spree})r
When a parachain signs up for a SPREE module, Polkadot guarantees that certain XCMP messages received by that parachain are being processed by the pre-defined SPREE module set of code. No similar cross-zone trust framework is offered by the Cosmos system.

Another significant difference between Cosmos and Polkadot consists in the way the blocks are produced and finalized. In Polkadot, because all parachain states are strongly connected to relay chain states, the parachain can temporarily fork alongside the relay chain. This allows the block production to decouple from the finality logic. In this sense, the Polkadot blocks can be produced over unfinalized blocks and multiple blocks can be finalised at once. On the other hand, the Cosmos zone depends on the instant finality of the Hub's state to perform a cross-chain operation and therefore a delayed finalization halts the cross-zone operations.

